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Abstract 


This document presents the China Education and Research Network 
(CERNET)’s IVI translation design and deployment for the IPv4/IPv6 
coexistence and transition. 


The IVI is a prefix-specific and stateless address mapping mechanism 
for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to 
an IPv6 network" scenarios. In the IVI design, subsets of the ISP's 
IPv4 addresses are embedded in the ISP's IPv6 addresses, and the 
hosts using these IPv6 addresses can therefore communicate with the 
global IPv6 Internet directly and can communicate with the global 
IPv4 Internet via stateless translators. The communications can 
either be IPv6 initiated or IPv4 initiated. The IVI mechanism 
supports the end-to-end address transparency and incremental 
deployment. The IVI is an early design deployed in the CERNET as a 
reference for the IETF standard documents on IPv4/IPv6 stateless 
translation. 


Status of This Memo 
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This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6219. 
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Introduction 


This document presents the CERNET IVI translation design and 
deployment for the IPv4/IPv6 coexistence and transition. In Roman 
numerals, the "IV" stands for 4, and "VI" stands for 6, so "IVI" 
stands for the IPv4/IPv6 translation. 


The experiences with IPv6 deployment in the past 10 years indicate 
that the ability to communicate between IPv4 and IPv6 address 
families would be beneficial. However, the current transition 
methods do not fully support this requirement [RFC4213]. For 
example, dual-stack hosts can communicate with both the IPv4 and IPv6 
hosts, but single-stack hosts can only communicate with hosts in the 
same address family. While the dual-stack approach continues to work 
in many cases even in the face of IPv4 address depletion [COUNT], 
there are situations where it would be desirable to communicate with 
a device in another address family.  Tunneling-based architectures 
can link the IPv6 islands across IPv4 networks, but they cannot 
provide communication between the two different address families 
[RFC3056] [RFC5214] [RFC4380]. Translation can relay communications 
for hosts located in IPv4 and IPv6 networks, but the current 
implementation of this kind of architecture is not scalable, and it 
cannot maintain end-to-end address transparency [RFC2766] [RFC3142] 
[REC4966] [RFC2775]. 


Analysis of IPv4-IPv6 Translation Mechanisms 


Since IPv4 and IPv6 are different protocols with different addressing 
structures, a translation mechanism is necessary for communication 
between endpoints using different address families. There are 
several ways to implement the translation. One is the Stateless IP/ 
ICMP Translation Algorithm (SIIT) [RFC2765], which provides a 
mechanism for translation between IPv4 and IPv6 packet headers 
(including ICMP headers) without requiring any per-connection state. 
However, SIIT does not specify the address assignment and routing 
scheme [RFC2766]. For example, SIIT uses IPv4-mapped IPv6 addresses 
[::ffff:ipv4-addr/96] and IPv4-compatible IPv6 addresses 
[::ipv4-address/96] for the address mapping, but these addresses 
violate the aggregation principle of IPv6 routing [RFC4291]. The 
other translation mechanism is Network Address Translation - Protocol 
Translation (NAT-PT), which has serious technical and operational 
difficulties; the IETF has reclassified it from Proposed Standard to 
Historic status [RFC4966]. 


In order to solve the technical difficulties in NAT-PT, the issues 
and the possible workarounds are: 
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1. NAT-PT disrupts all protocols that embed IP addresses (and/or 
ports) in packet payloads. There is little that can be done 
about this, other than using Application Layer Gateways (ALGs) or 
preferring protocols that transport DNS names instead of 
addresses. 


2. Loss of end-to-end address transparency may occur. End-to-end 
address transparency implies a global address space, the ability 
to pass packets unaltered throughout the network, and the ability 
to use source and destination addresses as unique labels 
[RFC2775]. A reversible, algorithmic mapping can restore some of 
this transparency. However, it is still not possible to ensure 
that all nodes in the existing Internet support such reversible 


mappings. 
3. The states maintained in the translator cause scalability, 
multihoming, and load-sharing problems. Hence, a stateless 


translation scheme is preferred. 


4. Loss of information due to incompatible semantics between IPv4 
and IPv6 versions of headers and protocols may occur. A partial 
remedy to this is the proper attention to the details of the 
protocol translation, for example, the error-codes mapping 
between ICMP and ICMPv6. However, some semantic differences 
remain. 


5. The DNS is tightly coupled with the translator and lack of 
address mapping persistence discussed in Section 3.3 of 
[RFC4966]. Hence, the DNS should be decoupled from the 
translator. 


6. Support for referrals is difficult in NAT-PT, given that 
translated addresses may leak outside the network where these 
addresses have a meaning. Stateless translation, algorithmic 
address mappings, and the decoupling of DNS from the translation 
process can help the handling of referrals. Nevertheless, it is 
still possible that an address-based referral is passed to 
someone who cannot employ it. For instance, an IPv6-only node 
may pass a referral based on an IPv6 address to a node that only 
understands IPv4. 


CERNET Translation Requirements 


The China Education and Research Network has two backbones using 
different address families. The CERNET is IPv4-only [CERNET] and 
CERNET2 is IPv6-only [CNGI-CERNET2], which fit in "an IPv6 network to 
the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" 
Scenarios in the IETF BEHAVE working group definition [BEHAVE] 
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[RFC6144]. In order to make CERNET2 communicate with the IPv4 
Internet, we designed the IVI mechanism and installed IVI translators 
between the CERNET and CERNET2. 


The requirements of the IVI mechanism are: 


1. It should support both IPv6-initiated and IPv4-initiated 
communications for the IPv6 clients/servers in "an IPv6 network". 


2. It should follow current IPv4 and IPv6 routing practice without 
increasing the global routing table size in both address 
families. 


3. It should be able to be deployed incrementally. 


4. It should be able to use IPv4 addresses effectively due to the 
IPv4 address depletion problem. 


5. It should be stateless to achieve scalability. 
6. The DNS function should be decoupled from the translator. 


The specific IVI design presented in this document can satisfy the 
above requirements, with the following notes: 


1. It restricts the IPv6 hosts to use a subset of the addresses 
inside the ISP's IPv6 block. Therefore, IPv6 autoconfiguration 
cannot be used for these IPv6 hosts. Manual configuration or 
autoconfiguration via stateful DHCPv6 is required. 


2. It defines a one-to-one mapping between IPv4 addresses and IPv6 
addresses; hence, the IPv4 addresses cannot be used efficiently. 
However, the IVI6 addresses can be used both for IPv6 clients and 
IPv6 servers. Due to this limitation, we suggest using IVI6 
addresses for servers. 


3. An ALG is still required for any applications that embed 
address(es) in the payload. 


4. Some issues with end-to-end transparency, address referrals, and 
incompatible semantics between protocol versions still remain, as 
discussed above. 


The IVI is an early design deployed in the CERNET for the stateless 
translation. The IETF standard IPv4-IPv6 stateless and stateful 
translation mechanisms are defined in [RFC6144], [RFC6052], 
[RFC6145], [RFC6146], and [RFC6147]. 
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Terms and Abbreviations 

The following terms and abbreviations are used in this document: 
ISP(i): A specific Internet service provider "i". 

IVIG4: The global IPv4 address space. 

IPS4(i): A subset of IVIG4 allocated to ISP(i). 


IVI4(i): A subset of IPS4(i); the addresses in this set will be 
mapped to IPv6 via the IVI mapping mechanism and used by IPv6 
hosts of ISP(i). 


IPG6: The global IPv6 address space. 
IPS6(i): A subset of IPG6 allocated to ISP(i). 


IVIG6(i): A subset of IPS6(i), and an image of IVIGA in the IPv6 
address family via the IVI mapping mechanism. It is defined as 
the IPv4-converted address in [RFC6144]. 


IVI6(i): A subset of IVIG6(i) and an image of IVI4(i) in the IPv6 
address family via the IVI mapping mechanism. It is defined as 
the IPv4-translatable address in [RFC6144]. 


IVI translator: The mapping and translation gateway between IPv4 and 
IPv6 based on the IVI mechanism. 


IVI DNS: Providing the IVI Domain Name System (DNS). 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL", when 
they appear in this document, are to be interpreted as described in 
[RFC2119]. 


The IVI Translation Algorithm 


The IVI is a prefix-specific and stateless address mapping scheme 
that can be carried out by individual ISPs. In the IVI design, 
subsets of the ISP's IPv4 addresses are embedded in the ISP's IPv6 
addresses, and the hosts using these IPv6 addresses can therefore 
communicate with the global IPv6 Internet directly and can 
communicate with the global IPv4 Internet via stateless translators. 
The communications can either be IPv6 initiated or IPv4 initiated. 
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The IVI mapping and translation mechanism is implemented in an IVI 
translator that connects between "an IPv6 network" and the IPv4 
Internet via the ISP’s IPv4 network, as shown in the following 
figure. 


/ The Ye KE / An \ / The \ 

| IPv4 |----- Xlate|------ | iPv6  |----- | IPv6 | 

\Internet/ = = ----- \Network/ \Internet/ 
<===> 


Figure 1: The Scenarios: "An IPv6 Network to the IPv4 Internet" and 
"the IPv4 Internet to an IPv6 Network" 


In order to perform the translation function between IPv4 and IPv6 
addresses, the translator needs to represent the IPv4 addresses in 
IPv6 and the IPv6 addresses in IPv4. 


To represent the IPv4 addresses in IPv6, a unique, prefix-specific, 
and stateless mapping scheme is defined between IPv4 addresses and 
subsets of IPv6 addresses, so each provider-independent IPv6 address 
block (usually a /32) will have a small portion of IPv6 addresses 
(for example, /40 defined by PREFIX), which is the image of the 
totality of the global IPv4 addresses, as shown in the following 
figure. The SUFFIX is all zeros. 


+-+-+-+-+-+-+ 
| IVIG4 | 
+-+-+-+-+-+-+ 
|| 
Ns 7 
M 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


| PREFIX | IPv4 addr | SUFFIX 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


Figure 2: Representing the IPv4 Addresses in IPv6 
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To represent the IPv6 addresses in IPv4, each provider can borrow a 
portion of its IPv4 addresses and map them into IPv6 based on the 
above mapping rule. These special IPv6 addresses will be physically 
used by IPv6 hosts. The original IPv4 form of the borrowed addresses 
is the image of these special IPv6 addresses, and it can be accessed 
by the IPv4 Internet, as shown in the following figure. The SUFFIX 
can either be all zeros, or some other value for future extensions. 


R-—R--—4R--4R--4--4R--4R--4--4--4--4--4--4--4--4--4--4 


| PREFIX | |IvI4| | SUFFIX 
+—--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 


Figure 3: Representing the IPv6 Addresses in IPv4 
3.1. Address Format 


The IVI address format is defined based on an individual ISP's IPv6 
prefix, as shown in the following figure 


|<- PREFIX -»|«- IPv4 address ->| <- SUFFIX -> | 
Figure 4: IVI Address Mapping 


where bit 0 to bit 31 are the prefix of ISP(i)’s /32 (e.g., using 
document IPv6 address IPS6=2001:db8::/32) in the CERNET 
implementation, bit 32 to bit 39 are all ones as the identifier of 
the IVI addresses, and bit 40 to bit 71 are embedded global IPv4 
space (IVIG4), presented in hexadecimal format (e.g., 


2001:db8:ff00::/40). Note that based on the IVI mapping mechanism, 
an IPv4 /24 is mapped to an IPv6 /64, and an IPv4 /32 is mapped to an 
IPv6 /72. 


The IETF standard for the address format is defined in [RFC6052]. 
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Routing and Forwarding 


Based on the IVI address mapping rule, routing is straightforward, as 
shown in the following figure 


/----- \ /----- \ 
( ISP's ) ==. 19240.2.2. 4-555-229-9225 2001:db8::2 -- ( ISP's ) 
( IPv4 )--|R1|------------- | IVI Xlate |------------ |R2|---( IPv6 ) 
(network) zs 192502. 01) s 2001:db8::1 -- (network) 
WU ind 
| | 
The IPv4 Internet The IPv6 Internet 


Figure 5: IVI Routing 
where 


1. IVI Xlate is a special dual-stack router, with two interfaces, 
one to the IPv4 network and the other to the IPv6 network (it is 
also possible to have a single interface configured with both 
IPv4 and IPv6 addresses). IVI Xlate can support dynamic routing 
protocols in IPv4 and IPv6 address families. In the above 
configuration, the static routing configuration can be used. 


2. Router R1 has an IPv4 route for IVI4(i)/k (k is the prefix length 
of IVI4(i)) with the next hop equal to 192.0.2.1, and this route 
is distributed to the Internet with proper aggregation. 


3. Router R2 has an IPv6 route for IVIG6(i)/40 with the next hop 
equal to 2001:db8::1, and this route is distributed to the IPv6 
Internet with proper aggregation. 


4. The IVI translator has an IPv6 route for IVI6(i)/(40+k) with the 
next hop equal to 2001:db8::2. The IVI translator also has an 
IPv4 default route 0.0.0.0/0 with the next hop equal to 
192.0.2.2. 


Note that the routes described above can be learned/inserted by 
dynamic routing protocols (IGP or BGP) in the IVI translator peering 
with R1 and R2. 


Since both IVI4(i) and IVI6(i) are aggregated to IPS4(i) and IPS6 (i) 
in ISP(i)'s border routers, respectively, they will not affect the 


global IPv4 and IPv6 routing tables [RFC4632]. 


Since the IVI translation is stateless, it can support multihoming 
when the same prefix is used for multiple translators. 
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Since the IVI translation can be implemented independently in each 


ISP's network, it can be incrementally deployed in the global 


Internet. 
Network-Layer He 
IPv4 [RFCO791] and 


different network-l 
and IPv6 headers MU 


ader Translation 


IPv6 [RFC2460] are different protocols with 

ayer header formats; the translation of the IPv4 
ST be performed according to SIIT [RFC2765], 
except for the source and destination addresses in the header, as 
shown in the following figures. 


Version (0x4) 
IHL 

Type of Service 
Total Length 


Version (0x6) 
discarded 
Traffic Class 


Payload Length - Total Length - 20 


Identification discarded 

Flags discarded 

Offset discarded 

TTL Hop Limit 

Protocol Next Header 

Header Checksum discarded 

Source Address IVI address mapping 
Destination Address IVI address mapping 
Options discarded 


Figure 6: IPv4-to-IPv6 Header Translation 


Version (0x6) 
Traffic Class 
Flow Label 
Payload Length 
Next Header 
Hop Limit 
Source Address 


Version (0x4) 
Type of Service 
discarded 


Total Length = Payload Length + 20 


Protocol 
TTL 
IVI address mapping 


Destination Address IVI address mapping 


IHL = 5 
Header Checksum recalculated 


Figure 7: IPv6-to-IPv4 Header Translation 
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The IETF standard for IP/ICMP translation is defined in [RFC6145], 
which contains updated technical specifications. 


3.4.  Transport-Layer Header Translation 


Since the TCP and UDP headers [RFCO793] [RFCO768] consist of 
checksums that include the IP header, the recalculation and updating 
of the transport-layer headers MUST be performed. Note that SIIT 
does not recalculate the transport-layer checksum, since checksum- 
neutral IPv6 addresses are used in SIIT [RFC2765]. 


The IETF standard for transport-layer header translation is defined 
in [RFC6145], which contains updated technical specifications. 


3.5. Fragmentation and MTU Handling 


When the packet is translated by the IVI translator, due to the 
different sizes of the IPv4 and IPv6 headers, the IVI6 packets will 
be at least 20 bytes larger than the IVI4 packets, which may exceed 
the MTU of the next link in the IPv6 network. Therefore, the MTU 
handling and translation between IPv6 fragmentation headers and the 
fragmentation field in the IPv4 headers are necessary; this is 
performed in the IVI translator according to SIIT [RFC2765]. 


The IETF standard for fragmentation and MTU handling is defined in 
[RFC6145], which contains updated technical specifications. 


3.6. ICMP Handling 


For ICMP message translation between IPv4 and IPv6, IVI follows the 
ICMP/ICMPv6 message correspondence as defined in SIIT [RFC2765]. 

Note that the ICMP message may be generated by an intermediate router 
whose IPv6 address does not belong to IVIG6(i). Since ICMP 
translation is important to the path MTU discovery and 
troubleshooting, the IPv4 representation of the non-IVIG6 addresses 
in the ICMP packets is required. In the current IVI prototype, a 
small IPv4 address block is used to identify the non-IVIG6 addresses. 
This prevents translated ICMP messages from being discarded due to 
unknown or private IP sources. 


The IETF standard for IP/ICMP translation is defined in [RFC6145], 
which contains updated technical specifications. 
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Application Layer Gateway 


Due to the features of 1-to-1 address mapping and stateless 
operation, IVI can support most of the existing applications, such as 


HTTP, Secure SHell (SSH), and Telnet. However, some applications are 
designed such that IP addresses are used to identify application- 
layer entities (e.g., FTP). In these cases, an Application Layer 


Gateway (ALG) is unavoidable, and it can be integrated into the IVI 
translator. 


The discussion of the use of ALGs is in [RFC6144]. 

The IVI DNS Configuration 
The DNS [RFC1035] service is important for the IVI mechanism. 
DNS Configuration for the IVI6(i) Addresses 


For providing authoritative DNS service for IVI4(i) and IVI6(i), each 
host name will have both an A record and a AAAA record pointing to 
IVI4(i) and IVI6(i), respectively. Note that the same name always 
points to a unique host, which is an IVI6(i) host, and it has IVI4 (i) 
representation via the IVI translator. 


DNS Service for the IVIG6(i) Addresses 


For resolving the IPv6 form of the global IPv4 space (IVIG6(i)), each 
ISP must provide customized IVI DNS service for the IVI6(i) hosts. 
The IVI DNS server MUST be deployed in a dual-stack environment. 

When the IVI6(i) host queries a AAAA record for an IPv4-only domain 
name, the IVI DNS will query the AAAA record first. If the AAAA 
record does not exist, the IVI DNS will query the A record and map it 
to IVIG6(i), and return a AAAA record to the IVI6(i) host. The 
technical specifications for this process are defined in [RFC6147]. 


The Advanced IVI Translation Functions 

IVI Multicast 
The IVI mechanism can support IPv4/IPv6 communication of Protocol 
Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC5771] 
[RFC3569] [RFC4607]. 
There will be 2^24 group addresses for IPv4 SSM. The corresponding 


IPv6 SSM group addresses can be defined as shown in the following 
figure. 
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IPv4 Group Address IPv6 Group Address 
232.0.0.0/8 f£3e:0:0:0:0:0:£000:0000/96 
232.255.255.255/8 £f3e:0:0:0:0:0:£0££:££££/96 


Figure 8: IVI Multicast Group Address Mapping 


The source address in IPv6 MUST be IVI6(i) in order to perform 
Reverse Path Forwarding (RPF) as required by PIM - Sparse Mode 
(PIM-SM). 


The interoperation of PIM-SM for IPv4 and IPv6 address families can 
either be implemented via an Application Layer Gateway or via static 
joins based on IGMPv3 and Multicast Listener Discovery Version 2 
(MLDv2) in IPv4 and IPv6, respectively. 


IVI Host Operation 
IVI Address Assignment 


The IVI6 address has a special format (for example, IVI4=192.0.2.1/32 
and IVI6-2001:db8:ffc0:2:100::/72); therefore, stateless IPv6 address 
autoconfiguration cannot be used. However, the IVI6 can be assigned 
to the IPv6 end system via manual configuration or stateful 
autoconfiguration via DHCPv6. 


o For the manual configuration, the host needs to configure the IVI6 
address and the corresponding prefix length, as well as the 
default gateway address and the DNS resolver address. 


o For the DHCPv6 configuration, the DHCPv6 will assign the IVI6 
address and the DNS resolver address to the host. The router in 
the subnet should enable router advertisement (RA), since the 
default gateway is learned from the router. 


IPv6 Source Address Selection 


Since each IPv6 host may have multiple addresses, it is important for 
the host to use an IVI6(i) address to reach the global IPv4 networks. 
The short-term workaround is to use IVI6(i) as the default source 
IPv6 address of the host, defined as the policy table in [RFC3484]. 
The long-term solution requires that the application should be able 
to select the source addresses for different services. 
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The IVI Implementation 
Linux Implementation 


An implementation of IVI exists for the Linux operating system. The 
Source code can be downloaded from [LINUX]. An example of how to 
configure an IVI deployment is shown in Appendix A. 


The IVI DNS source code for the IVIG6(i) addresses presented in this 
document can be downloaded from [DNS]. 


Testing Environment 


The IVI translator based on the Linux implementation has been 
deployed between [CERNET] (IPv4-only) and [CNGI-CERNET2] (IPv6-only) 
since March 2006. The pure-IPv6 web servers using IVI6 addresses 
[2001:250:£fca:2672:100::] behind the IVI translator can be accessed 
by the IPv4 hosts [TEST4], and also by the global IPv6 hosts [TEST6]. 
The pure-IPv6 clients using IVI6 addresses behind the IVI translator 
can access IPv4 servers on the IPv4 Internet. 


Two traceroute results are presented in Appendix B to show the 
address mapping of the IVI mechanism. 


IVI6 manual configuration and DHCPv6 configuration of the IPv6 end 
System have also been tested with success. 


Security Considerations 


This document presents the prefix-specific and stateless address 
mapping mechanism (IVI) for the IPv4/IPv6 coexistence and transition. 
The IPv4 security and IPv6 security issues should be addressed by 
related documents of each address family and are not included in this 
document. 


However, there are several issues that need special considerations, 
specifically (a) IPsec and its NAT traversal, (b) DNS Security 
Extensions (DNSSEC), and (c) firewall filter rules. 


o IPsec and its NAT traversal: Since the IVI scheme maintains end- 
to-end address transparency, IPsec could work with or without NAT 
traversal techniques. 


o DNSSEC: DNSSEC verification will be terminated at the IVI DNS for 


the "A record to AAAA record" translation. It would be fine to 
have a translation in a local IVI DNS server that also verifies 
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DNSSEC, or in the host, if the host both translates the DNS entry 
and again verifies DNSSEC validity. The DNSSEC discussion is in 
[RFC6147]. 


o Firewall filter rules: Since the IVI scheme maintains the end-to- 
end address transparency and there is a unique mapping between 
IPv4 and IPv6 addresses, the firewall filter rule can therefore be 
implemented for one address family, or mapped to another address 
family and implemented in that address family. However, the 
current IPv6 routers may only support the access-list or uRPF 
(unicast Reverse Path Forwarding) for the prefix length shorter 
than /64; there may a practical constraint for the construction of 
such rules. 


Except for the issues discussed above, we have not found special 
security problems introduced by the IVI translation in our 
experiments. 
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#!/bin/bash 

# open forwarding 

echo 1 > /proc/sys/net/ipv6/conf/all/forwarding 
echo 1 > /proc/sys/net/ipv4/conf/all/forwarding 


f config route for IVI6 = 2001:db8:ffc0:2:0::/64, 
# IVI4 192.0.2.0/24 


# configure IPv6 route 
route add -A inet6 2001:db8:ffc0:2:0::/64 \ 
gw 2001:da8:aaae::206 dev ethO0 


config mapping for source-PF = 2001:db8::/32 


# 
# config mapping for destination-PF 2001:db8::/32 


# for each mapping, a unique pseudo-address (10.0.0.x/8) 
# should be configured. 
f ip addr add 10.0.0.1/8 dev ethO 


commands. 


de de dE Se 


source-PF destination-PF 
/root/mroute 192.0.2.0 255.255.255.0 10.0.0.1 \ 
ethO 2001:db8:: 2001:db8:: 


# IPv6-to-IPv4 mapping 
# mroute6 destination-PF destination-PF-pref-len 


/root/mroute6 2001:db8:ff00:: 40 


Figure 9: IVI Configuration Example 
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IPv4-to-IPv6 mapping: multiple mappings can be done via multiple 
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The traceroute Results 


ivitraceroute 202.38.108.2 
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Note that the non-IVIG6 addresses are mapped to IPv4 document address 
192.0.2.0/24. 
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ivitraceroute6 www.mit.edu 


Src ivi4-202.38.97.205 src ivi6-2001:da8:ffca:2661:cd00:: 


dst host-www.mit.edu 
dst ip4-218.7.22.83 dst ivig-2001:da8:ff12:716:5300:: 


traceroute to 2001:da8:ff12:716:5300:: (2001:da8:ff12: 


30 hops max, 40 byte packets to not ivi 


1 2001:da8:ff0a:0:100:: 0.304 ms 0.262 ms 0.190 ms 
10.0:0.-t 
2 2001:da8:ffca:7023:fe00:: 0.589 ms * * 


202.112.35.254 


3 2001:da8:ffca:7035:4900:: 1.660 ms 1.538 ms 1.905 ms 


202.112.53.73 


4 2001:da8:ffca:703d:9e00:: 0.371 ms 0.530 ms 0.459 ms 


202.112.61.158 


5 2001:da8:ffca:7035:1200:: 0.776 ms 0.704 ms 0.690 ms 


202.112.53.18 


6 2001:da8:ffcb:b5c2:7d00:: 89.382 ms 89.076 ms 89.240 ms 


203.181.194.125 


7 2001:da8:ffc0:cb74:9100:: 204.623 ms 204.685 ms 
192.203.116.145 
8 2001:da8:f£fcf:e7£0:8300:: 249.842 ms 249.945 ms 


207.231.240.131 

9 2001:da8:ff40:391c:2d00:: 249.891 ms 249.936 ms 
64.57.28.45 

10 2001:da8:££40:391c:2a00:: 259.030 ms 259.110 ms 
64.57.28.42 


11 2001:da8:f££40:391c:700:: 264.247 ms 264.399 ms 
64.57.28.7 

12 2001:da8:ff£40:391c:a00:: 271.014 ms 269.572 ms 
64.57.28.10 

13 2001:da8:ffc0:559:dd00:: 274.300 ms 274.483 ms 
192.5.89.221 

14 2001:da8:ffc0:559:ed00:: 274.534 ms 274.367 ms 
192.5.89.237 

15 * * * 

16 2001:da8:ff12:a800:1900:: 276.032 ms 275.876 ms 
18.168.0.25 

17 2001:da8:f££12:716:5300:: 276.285 ms 276.370 ms 
18.7.22.83 


Figure 11: ivitraceroute6 Results 
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716:5300::), 


ms 
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ms 


ms 


Note that all of the IPv4 addresses can be mapped to prefix-specific 
IPv6 addresses (for example, 18.7.22.83 is mapped to 2001:da8:ff12: 


716:5300::). 
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